Déploiement d'une application PHP sur un serveur mutualisé OVH qui bloque le clonage d'un dépôt depuis une instance gitlab privée.
01/02/2021Le titre résume assez bien la problématique, lorsque l'on se connecte en SSH sur un serveur mutualisé PRO de chez OVH, il n'est pas possible pour des questions de sécurité de faire des requêtes HTTP(s), SSH, ICMP et autres vers l’extérieur ou du moins seulement vers certains domaines filtrés par OVH. Problème: j'utilise l'outil de déploiement Deployer (PHP) qui s'occupe de déployer mon application via un git clone d'un dépôt hébergé sur mon instance gitlab.
Deployer PHP
Deployer PHP est un outil open source écrit en PHP qui se charge via des recettes et des profils de déployer un projet PHP sur un/des serveur(s) à partir de ses sources et s'inscrit dans une démarche de déploiement continue. L'idée c'est d'automatiser toutes les étapes de configuration qui font passer un projet Web des sources à la production. On peux même le brancher dans la plupart des outils de CI/CD pour automatiser le déploiement dès qu'un commit est fait.
Le workflow de base
Sans trop rentrer dans les détails, le processus de déploiement réalise un ensemble de tâches exécutées séquentiellement sur le serveur distant en SSH. Si une tache échoue, le processus est arrêté, il est alors possible de rejouer les tâches jusqu'à la fin ou simplement de rollback l'installation en cours.
- prepare : préparation du processus, test de connexion au serveur SSH.
- lock : pose d'un verrou pour sécuriser le déploiement.
- release : création d'un nouveau répertoire pour accueillir la future release.
- update_code : récupération du code via un git clone.
- shared : gestion des ressources partagées (fichiers/dossiers spécifiques à l'instance : fichier de config, uploads...).
- writable : gestion des droits sur les ressources (fichiers/dossiers temporaires ou de cache).
- vendors : installation des dépendances via composer.
- clear_paths : nettoyage des ressources (fichiers/dossiers qui ne doivent pas se retrouver en production : Readme...).
- symlink : place la release fraîchement installé en current.
- unlock : suppression du verrou.
- success : fin du déploiement.
Deployer se base sur un système de liens pour assurer un déploiement à chaud et permettre l'utilisation de ressources partagées comme les images ou les fichiers de configuration. C'est ce qui selon moi en fait un outil relativement simple à mettre en place.
Le workflow est assez générique et suffisamment souple pour déployer à peu près tous type d'application PHP. Il existe même des recettes pour les applications et frameworks populaires.
Le fichier de configuration
L'outil se base sur un fichier de configuration yaml où l'on inscrit les différentes instances et informations serveur qui héberge l'application, on peut y inscrire plusieurs cibles : production, développement, alpha,... et même faire du déploiement parallèle pour les plus grandes infrastructures.
Attention, ce fichier peux contenir des informations sensibles, il est conseillé de ne pas l'ajouter directement à son dépôt git.
Le fichier deployer.php
C'est le fichier principal qui décrit la stratégie de déploiement de l'application. C'est ici que l'on renseigne les différents paramètres de déploiement, le workflow précis ainsi que des tâches supplémentaires que l'on souhaite intégrer à sa stratégie de déploiement (exemples: reset cache, envoi d'un mail...).
On peut lancer la commande de déploiement et se rendre compte que la tache update_code plante lamentablement dû à la restriction qui l’empêche de faire le git clone d'un projet sur mon instance gitlab privé.
La solution
Deployer permet grâce à son API de lancer des commandes shell localement et sur le serveur distant, l'idée est d'écrire une tache qui remplacerai le classique git clone distant par :
- clonage local.
- création d'une archive du dépôt local.
- envoi de l'archive sur le serveur.
- extraction de l'archive sur le serveur disant.
- nettoyage.
Ce qui se traduit par
Puis on modifie le worflow pour utiliser notre nouvelle fonction en lieu et place de update_code, ensuite on peut lancer le déploiement sans soucis.
Remarques
la tâche vendors réalise l'installation des dépendances via composer, il est intéressant de noter que les paquets sont téléchargés depuis des ressources externes (principalement github) qui ne sont pas concernées par la restriction.
Conclusion
Deployer PHP est pour moi un outil de référence qui réponds parfaitement à la majorité des problèmes inhérents à l'univers du déploiement et de la mise en production d'applications PHP. Il est facile à mettre en place, ne nécessite qu'une connexion SSH coté serveur et comme on la vue dans ce billet, il est extensible.